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1  Introduction 


Many  computing  centres  have  more  than  one  computer  in  their  facility, 
each  with  its  assorted  peripheral  devices.  Some  of  the  computers  may  be 
very  small.  For  such  machines  as  the  PDP-8/I,  a  reasonable  collection  of 
peripherals  usually  costs  several  times  more  than  the  central  processor. 
However  in  the  environment  there  may  exist  one  or  more  larger  machines 
for  which  the  overwhelming  peripheral  cost  is  better  balanced  by  a  complex 
CPU. 


Currently,  the  peripherals  of  one  machine  in  no  way  enhance  the  power 
of  any  other.  Thus  duplication  of  facilities  and  large  costs  result  if 
each  machine  is  to  have  complete  I/O  capability  including  discs  and  card 
readers  for  example. 

There  is  a  need  for  a  hardware  system  that  enables  the  I/O  capability 
of  one  machine  to  be  utilized  by  all  other  machines  in  the  system. 
Developments  involving  multi -computer  connections  at  other  Universities 
have  also  pointed  out  the  need  for  such  a  system  [1]. 

At  the  Computer  Research  Facility  of  the  University  of  Toronto  it  was 
desired  to  interconnect  three  digital  machines,  namely  an  IBM  360/44,  an 
Applied  Dynamics  AD/4  and  a  PDP-8/I.  After  a  preliminary  survey  of  the 
literature,  it  became  obvious  that  most  interconnection  schemes  fall  into 
one  of  two  equally  unsatisfactory  classes. 

The  first  class  consisted  essentially  of  special  one-of-a-kind  black 
boxes  intended  specifically  to  join  one  machine  to  another.  Generally 
speaking  designs  for  such  black  boxes  are  tightly  coupled  to  the  I/O  sub¬ 
systems  of  each  machine  and  are  therefore  potentially  high  speed  (~  800  K 
bits/sec) .  However,  they  in  no  way  lend  themselves  towards  general  use 
since  each  interface  is  typically  unique  [2,  3]. 

The  second  class  was  found  to  consist  essentially  of  a  communications- 
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oriented  interconnection.  Each  manufacturer  provides  some  facility  to 
connect  his  machine  to  a  telecommunications  system  using  data  sets,  modems, 
etc.  These  common  facilities,  being  independently  designed,  may  be  said 
to  loosely  couple  the  digital  machines.  Even  here,  where  there  might 
potentially  exist  a  standard  of  some  sort,  there  are  many  variations  in 
data  format  for  codes  and  procedures  for  use  of  the  lines  provided.  Most 
importantly  the  communication  is  at  relatively  low  speed  (10  bits/sec  to 
230  K  bits/sec)  due  to  the  need  for  compatibility  with  existing  common 
carrier  systems. 

It  seemed  therefore  that  there  was  a  need  for  a  general-purpose  high¬ 
speed  loosely-coupled  interconnection  system  -  a  system  designed  independ¬ 
ently  of  individual  computer  attributes. 

This  system  should  be  useful  in  at  least  two  situations.  The  first 
is  that  of  digital  machines  located  within  the  physical  span  of  each  I/O 
subsystem,  that  is  to  say,  in  the  same  building  and  capable  therefore  of 
high  speed  data  transfers. 


The  second  is  that  of  a  mixed  environment  in  which  both  computers 
and  general  digital  devices  must  communicate.  In  this  environment  a 
telecommunications  digital  machine  could  be  the  single  device  that 
extends  the  system’s  reach  to  other  systems  of  a  similar  or  disparate 
nature  [4],  This  possibility  presents  a  facility  that  is  high  speed 
for  local  intercommunication,  but  capable  of  being  extended  over  long 
distances  using  standard  telecommunications  techniques  at  standard  speeds 

As  a  result  of  these  considerations,  it  was  decided  to  design  and 
implement  a  general  system  interconnection  architecture,  called  Star-Ring 
At  the  present  time,  the  feasibility  of  the  system  has  been  tested  by  the 
specific  connection  of  a  System  360/44  Digital  Computer  and  an  Applied 
Dynamics /4  Analog  Computer. 
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2  Design  Goals  for  Digital  Coupling  Systems 


2 . 1  Data  Rate 


A  coupling  system  for  the  connection  of  digital  machines  must 
allow  a  data  rate  well  above  the  data  rate  of  any  connected  machine. 
This  ensures  that  a  non-standard  device  connected  through  a  coupler 
will,  as  far  as  each  machine  is  concerned,  be  capable  of  at  least 
the  data  rate  that  can  be  maintained  by  standard  peripherals. 


2.2  Interference 


The  system  should  guarantee  that  no  transmission  between  any  two 
machines  can  lock  out  the  system  for  other  transmissions  or  limit  the 
data  rate  of  a  concurrent  connection  below  some  guaranteed  minimum 
data  rate.  This  ensures  that  critical  periods  in  the  joint  functioning 
of  two  machines  do  not  result  in  failures  induced  by  interference  from 
other  machines  sharing  the  system. 


2 . 3  Modularity  and  Loose  Coupling 

The  system  should  present  a  common  interface  to  each  digital 
machine.  This  interface  should  be  as  simple  as  possible  and  for  each 
connection  should  disguise  the  complications  of  other  machines  connected 
to  the  system.  In  other  words,  the  I/O  interface  of  a  particular 
machine  need  only  concern  itself  with  the  interface  presented  by  the 
coupler,  not  the  interfaces  of  any  projected  sources  or  sinks  of  data  or 
control  information  also  coupled  to  the  system.  In  this  sense  it  may  be 
called  a  loosely  coupled  computer  system. 
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2 . 4  Response 

The  coupling  system  must  be  capable  of  real  time  response.  Not 
only  must  the  data  rate  be  high  but  the  set  up  of  data  transfer  must 
be  rapid  and  delay  in  transfer  minimal.  The  system  must  deal  with 
situations  in  which  small  amounts  of  data  requiring  quick  response  are 
sent  to  a  destination  machine  either  through  the  coupling  system  or 
otherwise.  Thus  delay  in  setting  up  a  connection  must  be  minimal.  This 
delay  cannot  in  general  be  amortized  over  long  data  strings  to  effectively 
produce  short  delays  on  a  word  basis  as  for  example  in  the  IBM  I/O  Channel 
initial  selection  sequence. 


2 . 5  Locking-out 

Sharable  devices,  such  as  a  CPU,  must  not  be  prevented  from 
communicating  in  a  multiplex  fashion  with  several  devices  in  the  system. 
This  implies  that  no  digital  machine  should  be  capable  of  tying  up  a 
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sharable  device  for  more  than  one  message  duration.  Thus,  the  system 
must  be  essentially  a  message  with  address  system.  Each  message  causes 
a  connection  to  be  made  to  the  destination  and  disconnection  after  the 
message  has  been  transferred. 


2.6  Hardware  Allocation 


For  various  reasons,  certain  devices  such  as  the  AD/4  or  a  disc 
file  should  be  capable  of  being  allocated  temporarily  to  one  digital 
machine  in  the  system  at  a  time.  In  these  cases,  blocks  of  messages 
must  be  guaranteed  contiguous  access  to  the  destination  machine.  This 
situation  is  analagous  for  example  to  the  sharing  of  a  disc  file  by 
several  programs  in  a  multiprogramming  system.  Each  program  may  use 
the  file,  but  each  use  must  be  completed  in  full,  not  interleaved,  if 
updates  occur. 
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3  Architecture  of  the  Star-Ring  System 


3.1  Introduction 


Before  describing  the  various  design  choices  made  within  the 
Star-Ring  System  itself,  it  is  appropriate  to  describe  the  general 
alternatives  for  system  layout  that  were  investigated.  After  the 
pros  and  cons  of  each  physical  layout  relative  to  the  design  goals 
have  been  introduced,  the  remaining  decisions  available  in  the 
architecture  of  the  Star-Ring  will  be  discussed. 


3 . 2  Physical  Organization  Alternatives 


In  determining  the  optimum  physical  layout,  several  alternatives 
were  considered.  As  has  been  described  previously  [5],  the  particular 
layout  called  Star-Ring  was  chosen.  The  following  is  a  brief  descrip¬ 
tion  of  the  main  points  in  this  consideration. 


3.2.1  Direct  Connection  of  Devices 


The  direct  connection  shown  in  Fig.  1  on  page  6  is  the  most 
obvious  approach.  It  is  capable  of  high  data  rate  and  quick 
response  since  each  interface  can  be  optimized  for  one  particular 
device  combination.  However,  a  third  computer  (C)  can  interfere 
with  the  interaction  of  computers  A  and  B  if  C  can  monopolize  the 
I/O  system  of  A.  Results  are  dependent  upon  A's  ability  to  cope. 
Using  this  example,  C  can  thus  be  shown  to  be  locked-out  from  A  if 
A  must  ignore  C  to  maintain  its  conversation  with  B.  Of  course, 
this  also  ruins  A's  response  time  as  well.  In  fact,  this  inter¬ 
ference  makes  the  hardware  allocation  goal  impossible  to  attain. 
Finally,  each  interface  is  unique  and  requires  a  new  design  for 
every  pair  of  devices.  Some  interfaces,  such  as  that  for  the  IBM 
360  system,  are  extremely  complicated  and  expensive  to  design  and 
construct.  They  also  imply  dedication  of  system  resources  within 
the  device  (e.g.,  a  high  speed  subchannel)  for  each  interface. 

This  could  be  very  costly  compared  to  a  more  shared  use  to  be 
described  later.  Moreover,  for  each  device  that  is  added  to  a 
system  of  N  devices,  N  additional  interfaces  must  be  built. 

To  avoid  many  of  these  problems  a  Bus  System  approach  was 
considered. 


3.2.2  Bus  System 


As  shown  in  Fig.  2  on  the  next  page,  each  device  is  inter¬ 
faced  to  a  cable  that  is  daisy-chained  from  one  device  to  another. 
The  system  is  modular  in  that  each  device  must  be  interfaced  only 
once  to  the  common  cable.  By  the  introduction  of  buffers  in  the 
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Fig.  1 


COMMON  BUS 


Fig.  2 
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interface,  timing  considerations  within  the  I/O  System  of  the 
destination  machine  can  be  ignored,  leading  to  a  loosely- 
coupled  computer  system. 

By  introducing  a  polling  scheme  [transferring  control 
around  a  loop  along  the  daisy  chain) ,  race  phenomena  encountered 
by  asynchronous  service  requests  can  be  avoided.  Each  interface 
may  use  the  bus  only  when  the  previous  interface  in  the  loop  has 
passed  on  control.  Because  of  this  scheme,  the  state  of  the  sys¬ 
tem  is  well  defined.  Only  one  transfer  of  data  is  taking  place 
at  any  one  time.* 

However,  new  problems  arise  in  this  scheme.  The  rate  of 
data  transfer  between  any  two  devices  is  reduced  considerably  as 
compared  with  a  direct  connection.  This  is  due  to  the  upper  limit 
on  rate  imposed  by  the  shared  cable  data  path.  Interfering  ^ 
multiplexed  transmissions  reduce  the  effective  data  rate  to  ^  of 
the  maximum  cable  data  rate  (for  N  devices) .  Since  the  cable  data 
rate  will  be  approximately  that  of  the  standard  I/O  subsystem  of  a 
device  this  leads  to  a  considerable  reduction  in  possible  data 
rates  from  device  to  device. 

Control  transfer,  mentioned  previously,  is  also  slowed  down 
by  the  cable.  The  additional  delay  required  for  passing  control 
also  tends  to  limit  the  data  rate.  Compounding  these  problems, 
the  length  and  bulk  of  the  cable  introduces  several  design  limita¬ 
tions.  Binary  coded  addressing,  as  opposed  to  discrete  address 
wiring  is  necessary  for  economic  reasons.  This  introduces  an 
additional  delay  in  data  transfer  along  the  cable  for  address 
decoding.  Word  size  must  also  be  small  to  conserve  cable.  This 
reduces  the  effective  data  rate  still  further.  Finally,  the  real¬ 
time  usefulness  of  this  scheme  is  reduced  by  the  slow  response  to 
service  requests  caused  by  control  transfer  and  address  decoding 
delay. 


The  Star-Ring  organization  described  next  keeps  the  advan¬ 
tages  of  the  Bus  System  and  avoids  the  drawbacks  described  above. 


3.2.3  Star-Ring  System  Layout 


This  organization,  shown  in  Fig.  3  on  the  next  page,  main¬ 
tains  the  modularity  of  the  bus  system  approach.  Each  device  is 
interfaced  only  once  to  the  control  ring  bus.  Because  each  inter¬ 
face  is  buffered,  a  device  must  only  be  conscious  of  the  timing 
considerations  of  Star-Ring.  Buffering  allows  overlap  of  data 
fetch  within  the  device  while  Star-Ring  attempts  to  transfer  the 
data  to  the  interface  of  the  destination  machine.  Polling  is  again 
used  to  give  control  to  each  interface  in  turn. 


*  This  fact  makes  allocation  and  lock-out  prevention  simpler  to  arrange 
as  will  be  seen  in  the  description  of  the  Architecture  of  Star-Ring. 
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STAR-RING  SYSTEM 


Fig.  3 
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What  Star-Ring  introduces  to  the  Bus  System  is  an  interacting 
division  both  in  time  and  space  of  slow  non-shared  data  periods  and 
data  areas  from  critically  high-speed  shared  data  periods  and  data 
areas . 


By  isolating  the  shared  bus  in  a  central  ring  which  is 
physically  small,  several  problems  of  the  simple  Bus  System  disappear. 
The  data  rate  of  the  small  bus  can  be  extremely  high.  In  fact  IC 
technology  (not  transmission  line  phenomena)  is  the  factor  that  sets 
the  upper  bound  on  data  rate.  In  the  system  constructed  24  bits  in 
parallel  are  transferred  in  approximately  140  ns.  Since  this  is 
considerably  less  than  the  period  per  word  in  the  I/O  system  of  any 
of  today's  devices,  our  first  design  goal  appears  to  be  achievable. 

Furthermore,  the  small  physical  size  of  the  bus  allows  us  to 
transfer  information  in  a  highly  parallel  way.  There  are  no  limiting 
cable  costs.  Thus,  the  effective  width  of  the  data  word  chosen  for 
implementation  could  be  stretched  to  24  bits.  This  makes  the  Ring 
bus  data  rate  extremely  high.*  Thus  the  effects  of  multiplex  inter¬ 
ference  on  the  shared  data  path  are  not  noticeable  and  do  not  degrade 
the  data  rate  below  that  of  current  I/O  subsystems. 

Summing  up,  non-shared  paths  are  the  cables  of  the  I/O  sub¬ 
systems  of  the  devices  themselves  and  the  shared  path  is  the  high 
speed  Ring  bus  within  the  Star-Ring  controller. 

In  addition,  the  small  physical  size  allows  one  the  luxury  of 
discrete  wire  addressing  which  in  turn  allows  the  separation  of  slow 
and  fast  data  periods.  As  will  be  explained  in  more  detail  later, 
addresses  from  the  I/O  subsystem  of  each  device  are  decoded  while 
buffers  are  loaded  with  data  from  the  I/O  subsystem  in  the  slow  data 
period. 

When  the  sending  interface  (Sender)  has  control  of  the  Ring 
bus,  the  destination  interface  (Acceptor)  is  addressed  using  the 
previously  decoded  discrete  wire  running  from  the  Acceptor  to  all 
Senders.  Thus  the  time  that  the  Sender  uses  the  bus  is  reduced  to 
the  minimum  to  transfer  data,  not  for  address  decoding. 

Obviously,  the  physically  small  bus  allows  transfer  of  control 
(or  polling)  around  the  Ring  bus  at  a  much  higher  speed  than  in  a 
cabled  bus  system.  Thus  polling  does  not  degrade  excessively  the 
maximum  possible  data  rate. 

In  addition,  the  rapid  transfer  of  control  and  data  together 
allow  single  word  with  address  transfers  at  a  high  enough  rate  to 
permit  real  time  response  as  detailed  in  the  design  goals  (2.4). 

The  Star-Ring  layout  has  many  advantages.  Using  this  layout 
as  a  starting  point,  the  architecture  of  the  Star-Ring  System  will 
be  discussed. 


*  7.14x24  Megabit/sec. 
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3.3  Modes  of  Data  Transfer 


The  primary  method  of  data  transfer  in  the  Star-Ring  system  is 
'message  with  address'.  In  particular,  a  device  presents  23  bits  of 
information  to  Star-Ring  including  data  and  destination  address. 
Star-Ring  then  forwards  the  data  to  the  destination.  Two  distinct 
modes  of  data  transfer  may  be  distinguished:  the  normal  or  multi¬ 
plex  mode  and  the  preselect  mode.  The  24th  bit  is  used  in  some  device 
interfaces  to  indicate  the  mode. 


3.3.1  Normal  or  Multiplex  Mode 

In  the  normal  mode,  a  source  of  information  (Sender)  will 
receive  control  from  the  source  further  'upstream'  in  the  control 
ring.  At  this  point  it  can  either  pass  on  control  or  use  control 
to  pass  on  a  23  bit  word  to  a  sink  of  data  (an  Acceptor)  on  the 
Ring  bus.  This  sink,  if  not  busy,  will  accept  the  data.  If  busy 
digesting  previous  data,  the  sink  will  indicate  to  the  source  to 
try  again  when  the  source  gets  control  next  time.  Whether  the 
23  bit  word  is  accepted  or  rejected,  the  Sender  will  pass  on  con¬ 
trol  unconditionally  to  the  next  Sender  in  the  Ring. 

For  Acceptors  connected  to  devices  which  can  use  data  in 
an  interleaved  fashion  from  several  sources  (e.g.,  a  general  pur¬ 
pose  computer),  this  mode  is  advantageous.  It  prevents  a  data 
source  which  generates  particularly  long  strings  of  data  from 
blocking  other  sources  from  access  to  the  device  accepting  the 
data . 


3.3.2  Preselect  Mode 


However,  as  was  mentioned  under  'Hardware  Allocation' 

(Sec.  2.6)  certain  devices  can  only  deal  with  one  source  of  data 
for  extended  periods  of  time  or  until  a  large  block  of  data  has 
been  transferred.  This  might  be  due  to  factors  such  as  the  single 
program  capability  of  a  machine  such  as  the  AD/4  or  the  need  for 
the  utmost  guaranteed  data  rate  on  a  device  such  as  a  high  speed 
disc  storage  facility.  In  these  cases,  a  preselect  mode  of  opera¬ 
tion  is  used. 

At  the  beginning  of  transmission  of  the  block  of  data,  the 
source  of  data  will  indicate  to  the  sink  that  the  sink  must  reject 
other  access  requests  from  other  sources.  This  is  called  Preselec¬ 
tion.  If  the  sink  accepts  this  mode,  then  it  will  appear  busy  to 
all  other  sources  until  the  original  source  releases  it  from  pre¬ 
select  mode.  If  it  does  not  accept  this  mode,  it  will  indicate 
this  to  the  source.  The  source  will  then  stop  its  attempt  to 
preselect  the  sink. 

However,  the  source  is  still  only  able  to  transfer  one  23  bit 
word  to  the  preselected  sink  for  each  time  that  it  gets  control. 
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Thus  interference  to  other  data  transmissions  between  other  pairs 
of  devices,  which  occur  interleaved  in  time  with  the  preselected 
transmission,  is  prevented. 
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4  Star-Ring  Standard  Interface 


4.1  Introduction 


The  Star-Ring  System  presents  a  standard  set  of  signals  to  sources 
and  sinks  of  data  in  the  system.  This  interface  should  be  simple  to 
facilitate  design.  Further,  to  make  the  design  highly  reliable,  con¬ 
trol  signal  operation  should  be  interlocked.  Because  of  the  buffered- 
bus  aspect  of  Star-Ring,  the  characteristics  of  other  machines  in  the 
system  do  not  alter  the  standard  interface  presented  to  each  single 
machine . 

The  interface  is  separated  into  two  parts:  One,  the  Sender  inter¬ 
face,  is  presented  to  sources  of  data.  Correspondingly,  the  Acceptor 
interface  is  presented  to  the  sinks  of  data. 


4.2  Sender  Interface 


The  source  device  is  presented  with  a  24  bit  register  for  write 
information.  See  Fig.  4  on  the  next  page.  Six  strobes  are  provided  so 
that  the  source  of  data  can  fill  it  4  bits  (or  any  multiple  of  4  bits) 
at  a  time.  This  allows  devices  with  various  word  lengths  to  be 
conveniently  connected.  Four  of  the  six  4  bit  fields  are  used  strictly 
as  data.  One  field  of  the  six  is  designated  a  control  field  which  may, 
if  needed,  route  the  data  at  the  destination.  The  destination  is  pointed 
at  by  the  remaining  'Address  To'  4  bit  field.  Only  3  of  the  four  bits 
in  the  latter  field  are  used  to  designate  destination.  The  fourth  bit 
is  normally  unused. 

Normally,  the  'Address  To'  field  should  be  loaded  first  so  that 
address  decoding  will  have  been  completed  before  data  loading  is  complete 
If  this  overlap  is  not  possible  and  all  23  bits  are  presented  in  parallel 
a  slight  delay*  for  address  decoding  of  the  destination  should  be  allowed 
After  this  delay  and  if  GO  has  been  issued,  the  Sender  will  send  the  data 
on  its  way. 

The  signalling  between  the  device  and  the  sender  is  accomplished 
through  interlocked  control  states  at  the  interface.  When  SRS  (Sender 
Response  Status)  is  true,  the  Sender  has  four  valid  status  bits  related 
to  the  last  data  transfer  on  the  Sender  status  lines.  SRS  also  indicates 
to  the  device  that  it  has  control.  Upon  analysing  the  status  and  filling 
the  data  buffers,  the  device  may  then  issue  GO  to  cause  the  Sender  to 
assume  control  and  send  data  on  its  way.  The  Sender  will  make  SRS  =  0, 
indicating  that  it  has  control  and  allowing  the  device  to  drop  GO.  After 
the  sender  has  attempted  to  transfer  the  data  and  accumulated  status,  it 
will  again  issue  SRS  to  give  control  back  to  the  device  to  restart  the 
cycle . 


*  i.e.,  GO  may  be  issued  as  the  Data  Strobes  go  to  one. 
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SENDER  INTERFACE  TO  SOURCE  DEVICE 


TO  AND  FROM 
SOURCE  DEVICE 


DATA  4 

DATA  3 

DATA  2 

DATA  1 

CONTROL 

' ADDR  TO' 

DATA  STROBES 

GO 

PREQ 

SRS 

DACC 

DNAVP 

STATUS 

DNAV 

PRESF 

SENDER 

*  Symbolic  only;  GO,PREQ,etc.  are  used  on  interface.  Assertion 
is  0  volts  for  all  signals,  except  the  Data  Strobes. 


Fig.  4 
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In  addition  to  the  GO  signal,  the  device  may  present  a  status 
bit  called  PREQ  (Preselect  Request).  If  the  Sender  is  able  to  attempt 
a  Preselect  mode  transfer,  then  the  transfer  will  go  on  normally  with 
SRS  indicating  the  status  after  the  transfer  attempt.  However  due  to 
certain  conflicting  situations  having  previously  been  established 
(e.g.,  the  Acceptor  is  already  in  preselect  mode  with  another  Sender, 
the  Sender  may  indicate  SRS  immediately  with  the  PRESF  (Preselect 
Response  False)  status  bit  set.  At  this  point  the  device  will  either 
stop  or  modify  other  conditions  and  retry. 

The  Sender  presents  3  other  status  bits  which  are  related  to  the 
immediately  previous  attempt  to  transfer  data  through  the  Ring  bus. 

DACC  (Destination  Accepts)  indicates  that  the  destination  has  accepted 
the  data.  The  remaining  two  status  bits  are  really  qualifiers  when 
DACC  =  0. 

DNAV  (Destination  Not  Available)  is  presented  when  the  Acceptor 
pointed  at  by  the  'address  to'  field  was  logically  disconnected  or 
physically  disconnected  from  Star- Ring. 

DNAVP  (Destination  Not  Available  for  Preselect)  is  presented  when 
the  destination  acceptor  refuses  to  accept  Preselection  because  (1)  it 
is  a  sharable  device,  or  (2)  it  has  already  been  Preselected  by  another 
Sender,  or  (3)  the  Acceptor  connected  to  the  source  device  has  Preselected 
some  sink.  Note  that  PRESF  is  presented  when  the  local  Acceptor  is  the 
cause  of  Preselect  failure,  but  DNAVP  is  presented  when  conditions  at  the 
destination  prevent  Preselection. 


4 . 3  Acceptor  Interface 

The  receiving  device  or  sink  is  presented  with  a  24  bit  register 
filled  by  transmission  of  the  contents  of  a  similar  field  at  the  Sender 
whose  3  bit  'Address  to'  field  pointed  at  that  sink  when  GO  was  issued. 

See  Fig.  5  on  the  next  page.  20  of  the  bits  in  this  register  are  iden¬ 
tical  to  those  in  the  Sender.  They  constitute  the  Data  and  Control  fields. 
The  device  connected  to  the  Acceptor  can  make  whatever  use  it  wants  of  the 
Data  and  Control  fields  and  can  access  them  in  4  bit  groups  using  the  5 
strobes  provided. 

The  4  remaining  bits  constitute  the  'Address  from'  field  which  is 
set  by  Star-Ring  to  indicate  the  source  of  the  data.  Again  only  3  of 
the  4  bits  in  this  field  are  significant.  A  strobe  is  also  provided  for 
this  field. 

As  at  the  Sender  interface,  signalling  between  the  Acceptor  and 
device  is  accomplished  through  interlocked  control  states  at  the  inter¬ 
face.  When  RAD  (destination  device  Ready  to  Accept  Data)  is  true,  the 
sink  device  board  presents  status  bits  DBAV  (Device  Board  Available)  and 
IPACC  (Inhibit  Preselect  in  the  Acceptor)  to  the  Acceptor.  This  indicates 
that  the  present  data  in  the  buffer  has  been  used  and  that  the  Acceptor 
can  accept  new  data.  RAD  going  to  one  causes  ADRDY  (Acceptor  Data  Ready) 
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ACCEPTOR  INTERFACE  TO  SINK  DEVICE 


TO  AND  FROM 
SINK  DEVICE 


DATA  4 

DATA  3 

◄ - 

DATA  2 

◄ - 

DATA  1 

◄ - 

- 

CONTROL 

'ADDR  FROM' 

DATA  STROBES 

5J? Tll,(  dbav 

AninvS  1  IPACC 

ADRDY  v 

PD 

ACCEPTOR 

- ► 

- ► 

- ► 

- ► 

• 

Symbolic  only;  RAD,  PD,  etc.  are  used  on  interface.  Assertion 
is  0  volts  for  all  signals,  except  the  Data  Strobes. 


Fig.  5 


to  go  to  zero  indicating  that  the  Acceptor  will  accept  new  data  from 
the  Ring  and  that  the  device  may  drop  RAD.  When  the  Acceptor  has 
loaded  the  new  data  using  AIS  (Acceptor  In  Strobe),  it  will  present 
ADRDY  =  1;  indicating  that  the  new  data  is  ready  and  valid  and  that 
the  Acceptor  status  bit  PD  (Preselect  Data)  is  valid. 

As  mentioned  previously,  RAD  is  accompanied  by  two  status  bits 
DBAV  and  IPACC  as  inputs  to  the  Acceptor.  DBAV  indicates  to  Sending 
controllers  whether  the  sink  device  is  logically  connected  to  the 
ring  or  not.  This  is  to  qualify  a  busy  status  bit  sent  back  to  a 
sender  to  cause  it  to  abort  attempts  to  transfer  data  and  not  wait  for 
the  busy  condition  to  change.  This  facility  is  used  in  the  360/44 
connection  to  cause  an  'operator  intervention  required'  message  on 
the  console.  DBAV  =  0  also  prevents  the  Acceptor  interface  from 
presenting  anything  but  busy  in  case  of  logic  indeterminancy  due  to 
logical  disconnection  of  the  device. 

IPACC,  if  true,  prevents  the  Acceptor  from  entering  into  any 
Preselect  mode  operations  (i.e.,  being  allocated  to  a  single  source 
of  data) . 


4.4  Acceptor  -  Sender  Preselect  Mode  Interaction 

In  the  Multiplex  mode  the  Acceptors  and  Senders  are  completely 
independent.  For  example,  a  device  could  use  only  the  Acceptor  inter¬ 
face  or  just  the  Sender  interface  while  another  device  could  use  the 
remaining  interface.  However,  the  more  common  situation  is  that  the 
device  is  both  a  source  and  sink  of  data.  The  I/O  system  of  such  a 
device  is  usually  capable  of  only  unindirectional  transfers  at  any  one 
instant  on  a  bus  shared  between  input  and  output.  Because  of  this 
restriction  Preselect  strings  should  not  be  accepted  by  the  Acceptor 
when  the  Sender  is  Preselected  out  and  vice-versa.  If  this  were 
possible,  preselects  in  and  out  would  be  set  up  by  the  Sender  and  the 
Acceptor  but  only  one  of  them  could  monopolize  the  I/O  bus  to  make 
maximum  use  of  the  data  rate  capabilities  of  that  bus.  One  of  the 
transmissions  would  be  held  until  the  other  is  over  and  overruns  in 
peripheral  devices  would  occur. 

Star-Ring  resolves  this  problem  and  allows  only  one  of  the  Acceptor- 
Sender  pairs  to  preselect  or  be  preselected  at  one  time  on  a  first  come 
first  serve  basis.  However,  the  remaining  member  in  a  pair  can  still 
communicate  on  a  multiplex  basis  if  the  other  is  preselected. 


4 . 5  Implications  of  Preselection 

As  noted  before,  the  Sender  associated  with  a  preselected  Acceptor 
is  prevented  from  attempting  to  engage  in  preselect  activity  itself. 

The  reason  for  this  restriction  is  two  fold:- 


*  Note  that  the  preselect  mode  does  not  require  this  facility  but  is 
not  hampered  by  it. 
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Preselection  may  sometimes  be  used  to  reduce  interference; 
allowing  at  least  a  certain  minimum  data  rate  into  an  Acceptor. 

This  may  in  turn  imply  that  the  bus  shared,  in  most  cases,  by  the 
Acceptor-Sender  pair  is  dedicated  or  monopolized  by  the  preselected 
Acceptor  which  is  trying  to  maintain  the  utmost  data  rate  (e.g., 
burst  mode  in  an  IBM/360).  If  the  Sender  associated  with  the  pre¬ 
selected  Acceptor  had  attempted  to  preselect  the  Acceptor  associated 
with  the  currently  Preselecting  Sender,  a  dead-lock  (or  deadly 
embrace)  can  occur  if  the  bus  shared  by  this  second  preselecting 
Sender  also  shares  a  bus  currently  in  a  burst-type  mode.  A  second 
consideration  is  that  given  the  motive  for  increased  data  rate  due 
to  lack  of  interference,  it  makes  no  sense  to  allow  both  Sender  and 
Acceptor  of  a  pair  to  both  attempt  a  high  data  rate  operation.  Like¬ 
wise,  the  Acceptor  associated  with  a  currently  Preselecting  Sender 
is  prevented  from  entering  into  Preselect  mode. 

It  should  be  noted  that  the  Preselecting  Sender  must  only 
attempt  data  transfers  to  the  Acceptor  that  it  has  previously  Pre¬ 
selected.  This  restriction  stems  from  certain  logic  assumptions  that 
were  based  on  the  decreased  interference,  rather  than  the  hardware 
allocation,  aspects  of  the  Preselect  mode. 

It  appears,  in  retrospect,  that  the  hardware  allocation  feature 
is  the  overriding  advantage  of  Preselect.  Thus,  future  modifications 
to  Star-Ring  should  allow  a  Sender  to  communicate  with  other  Acceptors 
when  it  is  communicating  in  Preselect  mode  with  one  or  more  Acceptors. 
This  necessitates  the  addition  of  more  logic  at  the  Device  Board  level 
to  help  control  Preselect  mode  operations  and  the  removal  of  certain 
control  logic  currently  mounted,  by  default,  on  the  Ring  Control  Unit. 

The  restriction  on  both  Sender  and  Acceptor  being  in  Preselect 
mode  concurrently  can  be  lifted,  if  the  bus  they  share  is  totally 
multiplex  in  nature.  This  is  possible  since  a  dead- lock  situation 
due  to  burst-type  activity  on  such  a  bus  is  not  possible.  Again,  a 
future  modification  to  Star-Ring  should  allow  selection  of  the  degree 
of  restriction  at  the  Device  Board  level. 

A  useful  restriction  which  could  be  provided  for  in  future  design 
is  that  certain  Acceptors  could  accept  only  transmissions  in  Preselect 
mode.  This  provides  for  devices  where  correct  operation  is  not  possible 
if  two  or  more  sources  are  attempting  to  communicate  with  it  at  once. 


17 


5  Internal  Star-Ring  Bus 


5 . 1  Passing  Control  Around  the  Ring 


Each  Sender  on  the  Ring  receives  control  (to  enable  it  to  use  the 
bus)  from  the  previous  sender  via  a  signal  called  ICI  (Interval  Control 
In) .  The  previous  Sender  generates  this  signal  when  it  has  finished 
using  its  own  control  interval. 

In  Fig.  6  on  the  next  page,  a  single  Sender  * N *  is  shown 
schematically  as  receiving  a  signal  ICI  and  generating  a  signal  ICO 
(Interval  Control  Out).  If,  at  the  time  ICI  rises  from  0  to  1,  the 
Sender  is  ready  to  transmit  data,  the  Sender  will  use  an  interval  of 
approximately  140  ns.  to  send  data  to  an  Acceptor  on  the  ring  and 
receive  status  back  from  that  Acceptor. 

During  this  time  it  also  sends  a  signal  ICO  to  the  next  Sender  on 
the  ring.  ICO  is  low  while  the  Sender  has  control  and  goes  high  when 
the  Sender  wishes  to  pass  on  control. 

If  the  Sender  was  not  ready  when  it  received  control,  then  it  holds 
ICO  low  for  about  60  ns.  then  allows  it  to  rise.  Thus  it  passes  on  con¬ 
trol  more  quickly  in  the  event  that  it  was  not  ready. 

The  scheme  described  above  optimizes  data  rates  for  each  Sender. 

If  a  given  Sender  is  the  only  ready  Sender,  it  will  receive  control 
many  more  times  per  second  than  it  would  if  all  Senders  were  ready  and 
were  transmitting  data.  Nominally,  if  all  Senders  are  always  ready, 
the  data  rate  of  each  Sender  is  limited  to  892  kilowords  per  sec.  If 
only  one  sender  is  ready,  it  can  achieve  a  data  rate  of  2.17  megawords 
per  sec.  (2.6  megabytes  to  6.5  megabytes  per  sec.). 

A  basic  problem  arises  in  accommodating  this  facility  of  adaptive 
data  rates.  It  concerns  the  asynchronous  decision,  at  the  moment  that 
the  Sender  receives  control,  whether  or  not  it  is  ready  to  transfer  data. 

A  straight  combinatorial  circuit  will  not  suffice  since  a  Sender  could  go 
from  not  ready  to  ready  while  it  was  in  the  act  of  passing  on  control  to 
the  next  Sender. 

To  avoid  this  problem,  one  could  use  a  clock  to  isolate  the  decision 
period  from  the  reaction  period.  However,  to  do  this  one  must  use  nominal 
logic  delay  specifications  to  limit  the  clock  rate.  Thus  one  does  not 
achieve  the  full  capability  of  the  IC  logic.  A  technique  for  making 
asynchronous  decisions  was  developed  and  applied  here.  See  Appendix  A  for 
a  complete  description. 


5 . 2  Multiplex  Mode  Data  Transfer 

Once  in  control,  a  Sender  will,  if  it  has  been  put  into  the  Ready 
state  by  a  GO  signal,  communicate  with  the  Acceptor  designated  by  its 
’Addr  to'  field.  Fig.  7  on  page  20  is  a  simplied  flow  chart  for  multiplex 
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PASSING  CONTROL  WITH  ICO  AND  ICI 


DATA, STATUS  AND  CONTROL 
BUS 


SENDER  N-l 
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1st  SENDER 
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INTERVAL  NOT  USED 
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DATA  TRANSFER 


ICO  FROM 
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Fig.  6 


19 


MULTIPLEX  MODE  DATA  TRANSFER 


Fig.  7 
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mode  (PREQ=0)  data  transfers.  It  shows  the  signal  interaction  between 
Sender  and  Acceptor  for  the  signals  shown  in  Fig.  8  on  the  next  page. 

It  can  be  readily  seen  that  control  of  the  data  transfer  sequence 
is  passed  back  and  forth  between  Sender  and  Acceptor  in  such  a  fashion 
that  propagation  delay  and  logic  delay  times  are  not  critical.  The 
annotations  in  Fig.  7  are  self-explanatory.  In  a  normal  operation,  the 
Sender  puts  data  on  the  bus  and  signals  to  the  Acceptor  with  Sel  (Select) 
that  the  data  is  valid  on  the  data  bus.  The  Acceptor,  after  a  delay  for 
propagation  and  logic,  strobes  the  data  with  AIS  which  arrives  at  the 
same  time  as  the  Select  signal,  into  its  buffers.  The  Acceptor  then 
signals  back  with  Cyc  (Cycle)  to  the  Sender  that  status  data  is  valid  on 
the  status  bus.  The  Sender,  after  the  propagation  delay  of  Cycle, 
strobes  data  by  making  Select  go  to  zero.  The  Acceptor  allows  Cycle  to 
go  to  zero.  Thus  the  Acceptor  signals  the  Sender  that  it  can  pass  on 
control  to  the  next  Sender  knowing  that  the  bus  lines  are  no  longer 
modified  by  itself  or  the  Acceptor. 

In  addition  to  the  normal  successful  data  transfer  attempts,  there 
are  various  modes  of  failure  to  transfer  data.  If  ACC=0  (Acceptor 
Accepted)  but  AV=1  (Acceptor  is  Available)  in  Acceptor  status,  the  Sen¬ 
der  will  retry  when  it  regains  control.  However,  if  ACC=0  and  AV=0  the 
Sender  signals  SRS=1  to  the  source  device  indicating,  with  DNAV=1,  that 
the  destination  sink  device  is  not  logically  connected  to  Star-Ring. 
Finally,  if  Cyc=0  the  Acceptor  has  been  physically  removed  or  is  faulty. 
The  time  out  circuit  in  the  Sender  will  cause  the  Sender  to  assume  the 
status  to  be  that  of  a  logically  disconnected  sink  device  in  order  that 
the  system  be  fail-soft.  This  is  made  possible  by  the  quiescent  state 
of  the  bus  being  ACC=0  and  AV=0. 

There  are,  in  effect,  two  data  transfers  taking  place:  (1)  Select 
In  (Sell)  indicates  to  the  acceptor  the  presence  of  23  bits  of  'data', 
'control',  and  'address  from'  bits  plus  2  Sender  'status'  bits. 

(2)  Cycle  (Cyc)  indicates  to  the  sender  the  presence  of  3  'status'  bits 
from  the  Acceptor  responding  to  Select  In. 

i 

The  next  section  will  deal  with  the  modifications  necessary  for 
preselect  mode  operation. 


5.3  Preselect  Mode  Data  Transfer 


In  addition  to  the  Select  line  to  the  appropriate  Acceptor,  the 
Sender  sends  accompanying  status  information  to  the  Acceptor.  There  are 
two  status  bits  B  (Begin)  and  PS  (Preselect).  If  B=0  and  PS=0 ,  then  the 
transfer  is  in  multiplex  mode.  If  PREQ=1  with  GO,  then  B  and  PS  are  used 
in  the  Preselect  transfer  sequence. 

When  the  first  Preselect  word  is  transferred  to  an  Acceptor,  B=l, 
PS=0  with  Select  'high',  the  Acceptor  sets  a  flip-flop  AIB  (Acceptor  is 
Blocked  to  other  Senders) .  This  signal  prevents  the  Sender  associated 
with  the  destination  acceptor  from  entering  into  any  Preselect  mode 
activity  (See  4.4  and  4.5).  The  Sender,  upon  receiving  ACC=1,  AV=1  and 
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PAV=1  (Acceptor  is  Available  for  Preselect) ,  sends  B=0  and  PS=1  with 
the  following  words  of  Preselect  mode  data.  The  Acceptor  will  respond 
only  to  Select  with  PS=1.  Thus  other  Senders  can  not  communicate  with 
the  Acceptor.  If  the  Acceptor  is  unable  to  enter  into  a  Preselect 
mode  transmission  at  this  time,  it  will  respond  immediately  with  ACC=0, 
AV=1  and  PAV=0. 

When  the  Preselect  is  finished,  the  Sender  will  send  the  last 
word  with  B=1  and  PS=1.  The  Acceptor  will  terminate  its  rejection  of 
other  Senders  and  make  AIB=0.  AIB=0  allows  the  Sender  associated  with 
the  destination  Acceptor,  which  has  prevented  from  entering  into  Pre¬ 
select  mode  while  its  associated  Acceptor  was  in  Preselect  mode,  to 
now  send  data  in  Preselect  mode.  (This  Acceptor-Sender  interaction  may 
be  unnecessary  in  certain  applications  -  see  Section  4.5). 

The  flow  chart  in  Fig.  9  on  the  next  page  has  the  additional  logic 
for  Preselect  mode  added  to  the  previous  simplified  one. 


23 


COMPLETE  DATA  TRANSFER 


Fig.  9 
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6  Physical  Implementation  of  Star-Ring 


It  must  be  noted  that  the  previous  specifications  for  the  stan¬ 
dard  interface  and  internal  bus  resulted  from  a  process  of  iteration 
between  specification  and  actual  design  until  a  final  state  was  attained 
in  which  the  IC  technology  of  today  was  best  utilized.  Inherent  in  this 
process  was  consideration  of  factors  such  as  the  size  of  IC  mother¬ 
boards  available,  the  size  of  edge  connectors,  the  relative  ease  of 
wire-wrapping  numbers  of  IC  sockets  versus  using  MSI,  the  speed  gained 
by  using  the  fastest  available  logic  versus  cost,  etc. 

This  iteration  between  specification  and  design  is  mentioned  to 
emphasize  that  it  was  found  that  black-box  minimization  techniques  do 
not  lead  to  good  solutions  in  the  light  of  overall  performance.  Overall 
performance  is  affected  only  slightly  by  state  minimization  techniques, 
indeed  often  worsened  by  them.  Certain  factors  were  found  to  be  far  more 
critical,  such  as  the  dilemma  of  whether  to  reduce  the  number  of  wire-wrap 
connections  while  increasing  the  IC  component  cost  for  MSI,  or  whether 
to  entertain  an  apparent  extravagence  in  the  number  of  flip-flops  to 
improve  maintainability,  etc.  None  of  these  problems  lend  themselves 
to  a  straightforward  application  of  some  algorithm.  In  summary,  the 
final  design  results  from  an  iterative  approach  to  optimizing  today's 
technology  by  unconventional  and  somewhat  intuitive  means. 

Engineering  drawings  and  detailed  circuit  descriptions  of  the  buffer 
and  ring  control  circuits  of  Star-Ring  will  be  available  through  CSRG  [6]. 


25 


7  Architecture  of  a  Third  Generation  Computer's  Interface  to  Star-Ring 


7.1  Introduction 


In  making  an  interface  to  a  third  generation  computer,  one  must 
be  aware  of  several  'firmware'  considerations.  Obviously,  the  inter¬ 
face  must  be  compatible  with  the  existing  I/O  hardware.  But  increasingly 
important,  with  ever  more  complicated  software  systems  that  form  an 
integral  part  of  the  third  generation  computer,  the  interface  must 
conform  to  the  software  system. 

This  must  be  done  in  a  circular  manner.  An  attempt  to  support  a 
non-standard  device  by  adding  additional  I/O  subroutines  would  be  met 
with  defeat  for  two  reasons.  The  first  reason  is  that  too  great  an 
effort  in  altering  the  system  would  be  involved.  Secondly,  as  newer 
versions  of  software  systems  arrive,  the  subroutines  would  have  to  be 
constantly  patched  to  be  compatible  with  the  new  system.  Only  by  making 
the  non-standard  device  appear  to  react  as  a  standard  device,  as  far  as 
the  system  software  is  concerned,  can  one  make  a  lasting  addition  to  a 
firmware  system. 

This  does  not  mean  a  great  loss  in  flexibility  of  control  over  the 
non-standard  device.  For  example,  operator  intervention  results  in 
response  to  the  presentation  of  certain  status  and  sense  bits  in  a  card 
reader.  Whenever  the  non-standard  device  requires  intervention,  a 
similar  sequence  of  status  and  sense  bits  could  be  presented  to  the 
'firmware'.  The  'firmware'  could  be  tricked  into  believing  that  such 
and  such  a  condition  exists  on  a  card  reader  and  into  typing  out  an 
intervention  required  message  to  the  operator.  As  newer  software  sys¬ 
tems  arrive,  they  will  all  have  to  support  these  quirks  of  a  card 
reader.  Thus  the  non-standard  device  will  normally  also  continue  to  be 
supported. 


7.2  Choice  of  I/O  Port  on  a  360/44 


On  a  model  44  there  exists  a  Direct  Word  Feature  [7]  that  can. 
reduce  response  time  for  real  time  jobs.  The  CPU  executes  an  instruc¬ 
tion  which  can  transfer  32  data  bits  into  and  out  of  the  computer.  This 
data  is  transferred  in  about  3  usee.  The  normal  I/O  channel  facilities, 
burdened  as  they  are  with  lengthy  I/O  software  support,  do  not  have 
extremely  short  nor  extremely  predictable  response  times.  In  addition, 
there  is  overhead  time  in  Channel  to  Control  Unit  housekeeping.  Their 
data  rate,  once  data  transfer  has  been  started,  is  of  the  order  of  1 
megabyte/sec. 

It  is  obvious,  that  the  Direct  Word  feature  would  be  of  more  use 
and  provide  higher  speed  in  a  system  requiring  quick  response  and  high 
transfer  rate  once  connected.  However,  this  would  not  allow  the  over¬ 
lapping  of  I/O  with  computation  available  with  a  channel.  Moreover, 
without  the  use  of  an  external  interrupt  [7]  the  CPU  would  be  forced  to 
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wait  for  the  connected  device  to  come  ready  by  checking  flags. 

Overriding  all  these  considerations  is  the  simple  fact  that  the 
44  is  the  only  360  with  Direct  Word  capability.  It  was  felt  that  an 
interface  to  Star-Ring  that  is  supported  in  all  360  computers  must  be 
built  to  prove  the  feasability  of  Star-Ring  with  third  generation 
computers  in  general.  Moreover,  software  support  for  the  Direct  Word 
feature  in  Operating  System  360  is  nonexistent  and  as  such  did  not 
fulfill  the  'firmware'  compatabi lity  requirement  of  the  Device  Board 
interface.  For  these  reasons  an  interface  to  a  multiplexor  channel 
was  used. 


7.2.1  Channels  and  Input/Output  Processors 

The  channel  concept  introduces  new  levels  of  automony  and 
therefore  responsibility  to  the  interface  designer.  No  longer 
do  certain  signal  lines  dictate  the  exact  flow  of  data  in  and  out 
of  the  interface.  Instead,  an  interface  to  the  channel  must  keep 
a  record  of  previous  transactions  with  the  channel  to  determine 
what  data  buffer  is  concerned,  which  direction  pertains  and  what 
kind  of  data  is  expected.  That  is  to  say,  the  sequential  logic 
that  formerly  resided  in  the  computer  mainframe,  with  a  majority 
of  combinatorial  logic  at  the  interface,  has  been  replaced  by  a 
distribution  of  sequential  logic  from  the  channel  through  to  the 
interface . 

This  interface  to  the  channel  is  called  a  control  unit  in 
IBM  terminology.  It  must  be  able  to  decode  commands,  remember 
commands,  make  byte  counts  of  data,  generate  parity,  autonomously 
execute  commands,  interrupt  the  channel  on  occasion,  generate  status, 
and  present  status  autonomously.  In  addition  to  this  basic  channel- 
oriented  housekeeping,  the  control  unit  must  interface  to  a  device, 
in  our  case,  Star-Ring. 


7.2.2  Real  Time  and  Shared  Use  of  Star-Ring 


When  data  arrives  from  Star-Ring  and  satisfies  a  Read  request 
previously  issued,  an  I/O  interrupt  occurs.  0S/360  determines  the 
device  causing  the  interrupt  and  transfers  control  back  to  the  wait¬ 
ing  task  which  is  associated  with  the  device  or  notifies  the  Task 
thru  a  Check  macro  that  the  data  has  been  received.  In  a  PCP  sys¬ 
tem,  the  transfer  of  control  to  a  Task  in  Wait  is  immediate.  In 
a  Multiprogramming  system,  the  control  may  be  delayed  by  some 
scheduling  algorithm. 

The  point  of  the  example  above  is  that  the  Task  can  be  con¬ 
sidered  to  be  interrupt  driven  by  the  arrival  of  the  data.  The  use¬ 
fulness  of  this  interrupt  driving  capability  is  dependent  on  the 
delay  between  data  arrival  and  activation  of  the  Task.  For  many 
classes  of  real-time  work  this  delay  is  not  unreasonable. 
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Operating  Systems  used  in  general  data  processing  have 
a  problem  with  shared  use  of  devices.  We  need  the  ability  to 
share  devices  to  implement  shared  use  among  Tasks  of  Star- Ring. 
Star-Ring  may  be  connected  up  to  seven  other  digital  devices. 

Each  task  in  a  Multiprogramming  system  may  want  to  share  the 
use  of  Star-Ring  to  communicate  in  a  multiplex  manner  with  the 
other  seven  devices.  There  must  be  added  a  facility  that  'owns' 
Star-Ring  in  the  OS/360  sense  and  passes  on  data  after  examining 
it  for  'Address  from'  criteria. 

Software  has  been  implemented  in  CSRG  to  support  the 
specific  features  of  Star-Ring.  This  software  circumvents  the 
IBM  Operating  System  conventions  with  regard  to  the  allocation 
of  devices,  to  permit  (1)  access  to  and  from  main  memory  of 
independent  tasks,  and  (2)  access  to  and  from  all  user-alloca- 
table  peripherals.  It  is  described  in  a  separate  report  [8]. 

A  similar  form  of  support  is  provided  by  RTOS ,  an  operating 
system  developed  by  NASA  for  360  computers  [9],  which  supports  a 
Star- Ring- like  device,  namely  the  IBM  2902  Multiplex  Line  Adapter. 
It  should  be  mentioned  that  in  addition  to  the  function  performed 
by  the  2902,  Star-Ring  allows  the  devices  connected  to  it  to 
communicate  with  each  other,  as  well  as  with  the  360  Computer. 


7.2.3  Control  Unit  Word  Length 

In  the  360  Interface,  word  length  could  have  been  any 
multiple  of  3  bytes  long:  in  general  N  x  3  bytes. 

Word  Length  >  3 


For  N  >  1,  the  360  would  do  a  Start  I/O  at  the  beginning  of 
data  transfer  and  N  x  3  bytes  would  be  transferred  3  bytes-at-a-time 
in  control-unit-forced-burst-mode  to  or  from  Star-Ring.  Star-Ring 
would  delay  the  Channel  for  at  least  1  usee  while  it  waited  for  con¬ 
trol  to  return  from  Star-Ring  after  transferring  each  3  byte  group. 

There  are  some  advantages  of  using  N  >  1.  Only  one  initial 
selection  sequence  (and  CCW  fetch  therefore)  is  used  for  all  N  x  3 
bytes.  For  long  predetermined  bursts,  data  rate  is  at  its  highest. 

However,  a  burst  for  large  N  is  incompatible  with  the  overall 
multiplex  design  philosophy  of  Star-Ring.  Other  tasks  or  jobs, 
within  the  360  sharing  the  Star-Ring  facility  would  not  have  access 
to  Star-Ring  until  the  burst  was  over.  In  addition,  a  long  output 
string  from  the  360  could  prevent  input  from  a  critically  timed 
device  and  vice-versa.  In  the  case  of  input,  response  to  a  previous 
output  could  be  delayed  past  some  crucial  limit  by  a  long  string  of 
unrelated  output.  Finally,  disastrous  results  could  occur  with 
unbuffered  card  readers  sharing  the  multiplexor  channel.  If  a  card 
'Read'  had  been  started  up  just  prior  to  an  exceptionally  long  out¬ 
put  string  to  Star-Ring,  possible  overruns  could  occur. 
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A  solution  could  be  obtained  by  operating  Star-Ring  in 
a  multiplex-by-3-byte  mode  on  the  channel  to  avoid  this  possible 
overrun.  Two  things  work  against  such  a  solution.  One  is  an 
increase  in  complexity  of  the  Star-Ring  Device  Board  to  allow 
such  a  capability.  The  other  is  that  the  advantage  gained  by 
only  one  SIO  or  initial  selection  is  outweighted  by  the  channel 
overhead  (not  seen  by  the  software)  required  to  service  the 
multiplexing  sequence. 

This  overhead,  added  for  multiplexing,  makes  long  word 
lengths  (N  >  1) ,  only  14%  faster  than  Command  Chaining  for  N  =  1 
besides  being  less  flexible  for  multi-usage  as  will  be  discussed 
next . 


Word  Length  =  3 


For  N  =  1,  there  are  two  modes  of  operation  of  data  trans¬ 
fer.  In  the  first  mode,  a  Start  I/O  is  issued  on  a  CCW  [7],  with¬ 
out  chaining,  for  each  3  bytes  transferred  over  Star-Ring,  from  or 
to  another  connected  device.  While  Star-Ring  is  transferring  the 
data,  the  Channel  could  be  communicating  with  other  devices 
including  the  other  360  channel  port  on  Star-Ring  carrying  data  in 
the  opposite  direction. 

The  scheme  for  N  =  1  ensures  that  only  multiplex  usage  of 
Star-Ring  by  programs  within  360  will  occur.  Lock  out  of  input  by 
output  and  interference  with  OS/360  scheduling  of  overrunnable 
devices  on  the  multiplexing  channel  will  not  occur. 

A  second,  more  sophisticated,  mode  of  operation  for  N  =  1 
involves  the  use  of  Command  Chaining  [7],  Input  and  output  can 
not  lock  each  other  out.  At  the  same  time,  the  CPU  is  not  involved 
with  data  transfer  more  than  once  for  long  strings  of  3  byte  Star- 
Ring  records.  Interference  to  previously  started  overrunnable 
devices  will  not  be  traumatic  since  the  Channel  is  not  locked  out 
by  Command  Chaining.  The  cost  of  this  'multiplex  insurance'  as 
mentioned  previously  is  only  14%  in  channel  overhead  as  opposed  to 
a  long  record  with  interrecord  Control  Unit  multiplexing  (N  >  1) . 

The  cost  in  additional  core  storage  for  CCW's  for  this  mode  can  be 
substantial,  however,  plus  the  overhead  of  fetching  many  channel 
commands .  Therefore  it  is  expected  that  the  next  version  of  the 
360  interface  will  support  multiplex-by- three  transmissions  for 
Preselect  mode  transmissions. 

One  general  conclusion  is  possible,  namely,  that  the  existence 
of  speed  losses  resulting  from  non-burst  mode  operation  demonstrates 
a  definite  weakness  in  360  hardware  and  OS/360  software;  for  it  is 
the  setting  up  for  data  transfer,  not  the  data  transfer  itself,  that 
slows  the  overall  rate. 
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7. 3  IBM  360  Multiplexor  Channel  Interface  to  Star-Ring 


There  are  basically  two  interfaces  to  the  Channel  to  be  made  and 
they  are,  for  the  most  part,  independent  of  each  other.  One  control 
unit  must  be  designed  to  be  a  sink  device  for  Star-Ring  while  another 
must  serve  as  a  source  device. 


7.3.1  Sink  Device  Interface 

To  the  360,  this  sink  device  to  Star-Ring  is  an  input 
device.  Star-Ring  presents  to  the  interface  a  24  bit  word  of 
data  and  various  control  and  status  signals  (see  Sec.  4.3). 


7.3. 1.1  Data  Format 


Because  of  the  8  bit  format  of  the  channel,  the 
24  bit  word  is  broken  down  into  3  bytes.  The  first  byte 
transferred  on  a  read  command  is  made  up  of  the  'Addr 
From'  field  in  bits  0  through  3  and  the  'Control'  field  in 
bits  4  through  7.  Similarly,  the  next  byte  contains  Data 
Groups  1  and  2  and  the  final  byte.  Data  Groups  3  and  4. 


7. 3. 1.2  Control  Unit  Appearance 

The  control  unit  must  appear  like  a  standard  input 
device  for  commands  used  and  status  and  sense  data  presented. 
Standard  features  of  this  control  unit  must  be  capable  of 
being  used  for  controlling  the  Star-Ring  interface.  Finally, 
the  device,  as  far  as  possible,  should  be  well  supported  by 
IBM  in  all  their  languages. 

A  search  was  made  of  many  IBM  input  device  component 
descriptions.  Happily,  a  2501  Card  Reader/Control  Unit  [10] 
has  sufficient  commands,  etc.,  to  be  suitable  for  the  inter¬ 
face.  It  is  a  standard  system  input  device  and  as  such  is 
very  well  supported  in  'firmware'  as  well  as  in  every  language. 

Thus  it  became  a  question  of  understanding  the  IBM/360 
channel  interface  and  firmware  and  logically  connecting  Star- 
Ring  Acceptor  Interface  signals  to  the  channel  signals  and 
sequences  pertinent  to  a  card  reader  in  an  appropriate,  useful 
way.  In  Star-Ring  terminology,  this  interface  is  called  a 
Device  Board. 


7. 3. 1.3  Overall  Operation  of  360  Input  Device  Board 

When  data  is  desired  by  the  CPU,  the  CPU  issues  a 
Start  I/O  instruction  to  the  Channel  which  sends  the  address 
of  the  Star-Ring  interface  on  the  360  I/O  bus.  The  Star-Ring 
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interface  will  respond  to  this  address  and  indicate  its 
presence  by  sending  back  its  address  to  the  Channel.  At 
this  point,  the  Channel  will  send  a  Read  command  to  the 
Star-Ring  Interface.  This  interface  is  called  the  Device 
Board. 


The  Device  Board,  if  it  does  have  data  for  the 
360  from  other  sources  on  the  Ring,  will  indicate  a 
command  acceptance  status  condition  (Status=0) .  At  this 
point  the  CPU  will  carry  on  with  processing  while  the 
Channel  and  Star-Ring  transfer  data  to  memory.  This 
initial  exchange  before  data  transfer  is  called  an 
'Initial  Selection  Sequence'  [11]. 

The  Device  Board  will  operate  in  'Control  Unit 
Forced  Burst  Mode'  [11]  and  transfer  the  3  bytes  of  data 
into  core.  After  the  third  byte,  the  Device  Board  will 
disconnect  from  the  Channel.  The  Device  Board  will  make 
RAD=0  at  the  Acceptor  Interface  indicating  that  the  360 
Ring  Control  Unit  CRCU)  can  accept  more  data  as  the  old 
data  need  no  longer  be  saved. 

The  Device  Board  will  respond  to  a  Start  I/O 
sequence,  upon  a  Read  command,  with  Busy  Status  (Status=5) 
until  the  Acceptor  Interface  has  ADRDY=0  again.  ADRDY=0 
indicates  that  new  data  is  ready  from  Star-Ring. 

Usually,  however,  the  I/O  Supervisor,  through  the 
Channel,  will  not  try  a  second  Read  if  it  finds  Busy  status 
first.  It  will  wait  until  the  Device  Board  reports  Ready 
status  (Device  End)  asynchronously  through  a  'Control  Unit 
Initiated  Selection  Sequence'  [11].  At  this  point  the 
interrupted  CPU  will  attempt  a  Read  and  succeed  again  as 
before . 


In  addition  to  this  basic  data  transfer  mechanism, 
the  Device  Board  must  accept  Control  and  Sense  commands  in 
order  to  be  firmware  compatible.  When  these  commands  are 
decoded,  a  trivial  subset  of  a  real  card  reader  control  unit's 
possible  reactions  is  effected  and  the  firmware  satisfied. 

Finally,  the  Channel  may  issue  a  Test  I/O  command. 
When  this  happens,  the  Device  Board  will  transfer  one  byte 
of  status  data  back  to  the  channel. 


7.3. 1.4  Programming  Considerations 

The  Device  Board  should  be  treated  as  a  card  reader 
at  address  '00B' .  The  record  length  is  fixed  at  3  bytes 
(i.e.,  the  first  3  columns  for  a  card  reader). 
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The  value  of  each  byte  may  be  from  0  to  255.  This 
may  require  special  consideration  for  certain  languages. 
Fortran,  for  example,  will  require  Alphameric  (A)  format 
specification.  Any  access  method  in  Assembler  will  work. 
Fig.  10  on  the  next  page  shows  the  format  of  the  three 
bytes  of  data  in  core. 

The  Preselect  Data  bit  indicates  to  the  program 
that  the  following  data  records  are  all  from  the  same  source 
on  Star-Ring  as  long  as  that  bit  is  on.  This  means  that  the 
'address  from'  field  need  only  be  examined  once  for  each 
block  of  Preselect  Data. 

Command  chaining  is  possible  and  would  hasten  the 
transfer  of  data  in  large  contiguous  blocks  that  require  no 
inter-record  calculations  by  the  CPU. 


7. 3. 1.5  Physical  Implementation  Details 

Engineering  drawings  and  detailed  circuit  descrip¬ 
tions  for  the  Device  Boards  used  in  the  360  interface  will 
be  available  through  the  Computer  Systems  Research  Group  [6]. 


7.3.2  Source  Device  Interface 

As  with  the  sink  device,  a  search  was  made  of  IBM's  component 
descriptions  for  a  reasonable  output  device.  The  2821  Control  Unit 
for  1403  Line  Printer  and  Card  Punch  [12]  was  found  to  accept  many 
different  write  and  control  commands.  It  was  chosen  as  the  model 
for  the  Source  Device  Board. 


7. 3. 2.1  Data  Format 


The  data  format  used  here  is  analogous  to  that  used 
for  the  sink  device  interface.  The  first  byte  transferred  on 
a  'Write'  command  is  made  up  of  the  'Addr  to'  field  in  bits  0 
through  3  and  the  'Control'  field  in  bits  4  through  7. 
Similarly,  the  next  two  bytes  contain  Data  Groups  1  through  4 


7. 3. 2. 2  Overall  Operation  of  360  Output  Device  Board 


The  Device  Board  goes  through  an  initial  selection 
sequence  analogous  to  that  for  the  input  Device  Board.  Subse 
quently,  it  accepts  printer  'Write'  commands  and  transfers  3 
bytes  of  data  from  memory  to  the  Star-Ring  Sender  Standard 
Interface.  Again  data  transfer  is  in  'Control  Unit  Forced 
Burst  Mode ' . 
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360  INPUT  DATA  FORMAT 


0  I  2  3  4  5  6  7  8  9  10  II  12  13  14  15  16  17  18  19  20  21  22  23 
0123456701  2  3456  70  I  23  4  56  7 


U  A 


DATA  I  DATA  2  DATA  3  DATA  4 
-CONTROL  FIELD 


- 'ADDRESS  FROM'  FIELD 

PRESELECT  BIT,  1  INDICATES  PRESELECT  MODE 
ADDRESS  POINTED  AT  BY  CCW  WITH  READ  COMMAND 


Fig. 10 


360  OUTPUT  DATA  FORMAT 


- j - 

1 _ 

— 1 

i 

AA 

A 

A 

DATA  1  DATA  2 

DATA  3  DATA  4 

- CONTROL  FIELD 

- 'ADDRESS  TO7  FIELD 

NOT  USED  YET,  PRESELECT  INDICATED  BY  CCW 
ADDRESS  POINTED  AT  BY  CCW  WITH  WRITE  COMMAND 

Fig. 11 
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If  the  Device  Board  is  readdressed  by  the  Channel 
before  Star-Ring  has  delivered  the  data  to  the  destination 
Acceptor,  then  the  Device  Board  will  respond  with  'Busy' 
status.  Again,  as  in  the  case  for  the  input  Device  Board, 
the  CPU  will  be  interrupted  when  the  output  Device  Board 
can  again  accept  more  data. 

The  output  Device  Board  will  accept  'Control' 
commands  for  firmware  compatibility.  However,  unlike  the 
input  Device  Board,  the  'Sense'  command  is  used  for  unusual 
condition  handling. 

If  the  Sender  Interface  reports  DNAV=1  (Destination 
not  Available),  then  the  'Unit  Check'  status  bit  is  set  when 
Status  is  sent  to  the  Channel.  OS/360  upon  receiving  this 
status  will  issue  a  'Sense'  command.  The  sense  data  sent 
back  will  be  such  as  to  cause  operator  intervention  (end  of 
forms  for  a  printer).  The  operator  will  ready  the  destina¬ 
tion  device  and  flip  a  switch  on  Star-Ring  causing  the 
Channel  to  receive  'Ready'  status.  This  will  cause  0S/360 
to  reissue  the  'Write'  command  to  the  Device  Board  and  data 
transfer  will  proceed. 

A  'Write'  command  modifier  [11]  was  included  to 
clear  the  input  device  board  of  any  outstanding  data  that 
may  have  been  left  by  a  previous  program.  The  'Control' 
command  with  similar  modifier  bits  to  that  of  this  'Write' 
command  will  also  clear  the  input  device  board. 

A  further  variation  on  the  'Write'  command  causes 
data  to  be  transferred  in  Preselected  mode  to  the  destination 
Acceptor.  Subsequent  models  of  the  360  Sender  Device  Board 
will  probably  use  bit  0  to  indicate  preselect,  in  order  to 
provide  compatibility  with  the  Acceptor  Device  Board. 


7. 3. 2. 3  Programming  Considerations 

The  output  Device  Board  should  be  treated  as  a  1403 
Line  Printer  at  address  'OOF'.  The  record  length  is  fixed 
at  3  bytes  (i.e.,  the  first  3  print  positions  on  a  line 
printer. 


As  for  the  card  reader,  each  byte  may  have  a  value 
0  to  255  and  requires  the  same  attention  with  respect  to 
languages  as  the  input  Device  Board.  Fig.  11  on  page  33  shows 
the  format  of  the  three  bytes  of  data  in  core. 

The  Device  Board  accepts  three  different  'Write' 
commands.  The  first  write  command  X ' 0 1 '  transfers  the  data 
to  the  destination  in  Multiplex  mode. 
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The  second  'Write'  command  X ' 1 1 '  (Write  and  space 
2  after  print)  has  the  same  major  effect  as  X ' 0 1 ' .  In 
addition,  it  clears  the  buffers  of  the  X'OOB'  Input  Device 
Board  thus  cleaning  up  the  remnants  of  a  previous  program. 

The  third  'Write'  command  X ' 09 '  (Write  and  space 
1  after  print)  transfers  the  data  to  the  destination  in 
Preselect  mode  as  long  as  this  command  is  used. 

Command  chaining  is  possible  for  large  contiguous 
blocks  of  data  to  avoid  involving  the  CPU  in  data  transfer. 

Sense  data  returned  from  a  'Sense'  command  can  be 
analysed  by  an  Assembler  routine.  If  the  sense  byte  indi¬ 
cates  X'40',  (Intervention  Required  End  of  Forms),  then  the 
destination  acceptor  was  either  not  available  or  not  availa¬ 
ble  for  preselection  for  more  than  5  sec.  A  sophisticated 
handler  at  this  point  could  output  specific  messages  to  the 
operator  to  correct  the  condition.  However,  OS/360,  by 
default,  will  output  'intervention  required'  to  the  operator 
when  this  sense  data  implies  something  must  be  reported 
(i.e.,  after  Unit  Check;  Status=2) . 
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8  Architecture  of  Applied  Dynamics/4  Interface  to  Star-Ring 


8.1  Introduction 


The  AD/4  is  a  Hybrid  Computer  designed  for  digital  interface  and 
control  [13].  The  source  of  digital  control  signals  can  be  the  opera¬ 
tor's  console  of  the  AD/4  itself  and  its  digital  input  buttons  or  more 
importantly  a  digital  computer  with  supporting  software. 

The  connection  to  an  external  computer  is  divided  by  the  manufac¬ 
turer  normally  into  two  parts.  The  Hybrid  Interface  Facility  (HIF)  is 
located  in  the  AD/4  computer  mainframe  and  provides  line  receivers  and 
line  drivers  to  give  access  to  a  well  defined  set  of  control  inputs  and 
outputs .  The  second  part  of  the  connection  is  the  Remote  Interface 
Facility  (RIF).  This  is  located  near  the  digital  computer  and  normally 
translates  the  control  lines  provided  by  the  HIF  into  format  acceptable 
to  a  standard  digital  computer  input/output  device  (for  example,  a  2701 
Parallel  Data  Adapter  for  an  IBM  360  computer) . 

In  the  Star-Ring  system,  the  HIF  is  interfaced  directly  to  Star- 
Ring.  This  interface  is  called  the  AD/4  Device  Board  and  replaces  the 
function  of  the  RIF  as  far  as  the  HIF  is  concerned.  As  a  result,  once 
interfaced,  the  AD/4  is  capable  of  being  controlled  by  any  digital  com¬ 
puter  connected  to  Star- Ring. 

The  AD/4  can  take  advantage  of  this  accessabi lity  to  more  than  one 
computer  to  enhance  user  convenience.  Production  jobs,  requiring  large 
computational  control  programs,  can  be  run  on  the  360/44,  controlling 
the  AD/4.  Diagnostic  and  teaching  level  jobs  can  be  programmed  on  the 
PDP-8/I  (to  be  connected  to  Star-Ring  in  the  future).  This  reduces  inter¬ 
ference  to  the  360/44  and  resulting  high  costs  of  less  complicated  but 
more  time-consuming  jobs. 


8. 2  .The  Hybrid  Interface  Facility's  Interface  to  Star-Ring 


The  HIF  interface  to  Star-Ring,  the  AD/4  Device  Board,  is  divided 
into  two  major  sections:  the  Interrupt  Handler  and  the  Control  Command 
Handler.  Control  of  this  interface  is  passed  from  one  Handler  to  the 
other  in  a  circular  manner  (similar  to  the  passage  of  control  within  the 
Star-Ring  Internal  Bus).  Each  handler  takes  advantage  of  the  period 
during  which  it  can  control  the  interface  when  external  signals  signify 
that  it  should.  Each  handler  can  only  lock  out  the  other  as  long  as  it 
needs  to  handle  either  a  single  change  in  interrupt  status  or  accept  and 
execute  one  control  command  from  Star- Ring. 


8.2.1  Command  and  Data  Format 


The  Star-Ring  Monitor  software  [8]  supports  generalized 
communication  between  machines  via  the  Star-Ring  hardware.  The 
four  bit  control  field  (bits  4  to  7  of  the  Star-Ring  word)  is  used 
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in  the  following  way: 

1)  bit  4  is  used  to  distinguish  between  ’data'  (0)  and 
' message 1  (1) ; 

2)  bit  5  is  used  to  indicate  that  only  the  first  (0)  or 
both  (1)  of  the  data  bytes  are  valid; 

3)  bits  6  and  7  are  used  to  differentiate  among  four  (00 

to  11)  pseudo-files.  These  files  are  read-only  or  write- 
only. 

Both  '’commands"  and  "data"  may  be  sent  to  the  AD/4,  and 
each  may  imply  a  read  operation  or  a  write  operation.  In  addition, 
it  is  desirable  to  be  able  to  send  commands  to  the  Device  Board 
itself,  to  enable/disable  interrupts,  etc.  Data  returning  from 
the  AD/4  may  be  either  the  result  of  a  read  operation,  or  the 
status  after  a  write  operation.  In  addition,  an  interrupt  condi¬ 
tion  may  be  presented. 

The  operation  of  the  AD/4  is  in  two  cycles  -  an  Access  cycle 
and  an  Execute  cycle.  The  Access  cycle  places  the  desired  command 
in  the  operation  register,  (’OR* , see [13]) ,  and  the  Execute  cycle 
executes  the  command,  using  or  presenting  data  or  status  as  appro¬ 
priate.  Certain  write  commands  and  all  read  commands  can  combine 
these  cycles  if  desired.  The  remaining  write  commands  need  two 
Star-Ring  data  transfers.  Also,  there  is  a  class  of  read  operations 
which  can  make  use  of  one  Access  followed  by  many  Executes. 


8.2.2  The  Control  Command  Handler 


The  Acceptor  Interface  presents  24  bits  of  information  to  the 
Control  Command  Handler.  The  'Address  From'  Field  is  used  to  set 
the  'Address  To'  field  of  the  Sender  Interface  so  that  the  AD/4 
responses  go  back  to  the  controlling  digital  computer.  The  control 
field  is  used  to  indicate  the  destination  of  the  information,  or  an 
action,  and  is  set,  for  the  reply,  to  indicate  the  source.  The 
three  possible  formats  for  the  Star-Ring  word  are  shown  in  Fig.  12 
on  the  next  page. 
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Format  for  commands 

going 

to  AD/4 

AAAAMLFF  XCCCCCCC 

EXXXXDDD 

AAAA  - 

1010 

destination  machine  (AD/4) ,  preselected 

M  - 

1 

message 

L  - 

1 

2  data  bytes  valid 

FF  - 

00 

file  zero  (read  commands) 

01 

file  one  (write  commands) 

X  - 

0 

not  used 

ccccccc  - 

(0-177) g  command  code 

E  - 

0 

access  only 

1 

access  and  execute 

xxxx  - 

0000 

not  used 

DDD  - 

(0-7) 

data  for  write  immediate 

Format  for  data  going  to  AD/4 

AAAAMLFF  DDDDDDDD 

DDDDDDDD 

AAAA  - 

1010 

destination  machine,  preselected 

M  - 

0 

data 

L  - 

1 

2  data  bytes  valid 

FF  - 

00 

file  zero  (execute) 

01 

file  one  (change  state  of  star-ring)* 

D.  .  .D 

two  bytes  of  data 

*  File  one  (FF=01) 

will  i 

mply  that  D...D  contains  a  change  state 

command  for  the  star-ring  interface  board. 

Format  for  returning  data  from  AD/4 


AAAAMLFF  DDDDDDDD  DDDDDDDD 


AAAA  -  0010 
M  -  0 
1 

L  -  1 
FF  -  10 
11 


D .  .  .  D 


source  machine,  not  preselected 
data  (read  or  status) 
message  (interrupt  data) 

2  data  bytes  valid 
file  two  (data  from  read  commands) 
file  three  (status  from  write  commands) 
or  (if  m=l)  interrupt  data) 

two  bytes  of  data 


Fig.  12 
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Access  a  Read  Op  Code 
M=1 ,  FF=00,  E=0 . 

This  command  causes  the  high  order  8  bits  in  the  Data  Field 
(Data  Groups  1  and  2)  to  become  the  new  operation  code  in  the 
Operation  Register  ('OR',  see  [13]).  It  also  sets  the  Write  Op 
Code  Flag  to  zero  (WOCF=0) .  See  "Execute  the  Op  Code"  for  the 
use  of  WOCF. 

Access  a  Write  Op  Code 

M=l,  FF=0 1 ,  E=0 . 

This  command  modifies  the  'OR'  in  the  same  way  as  above. 

However,  it  sets  the  WOCF  to  one. 

Execute  the  Op  Code 

M=0 ,  FF=00 . 

If  WOCF  has  been  previously  set  to  a  one,  then  a  Write  Op 
Code  is  in  the  'OR'.  Data  in  Data  Groups  1,  2,  3,  4  are  put  on 
the  AD/4-HIF  Input  Bus  (IB).  The  Op  Code  currently  in  the  'OR' 
will  determine  what  use  is  made  of  these  data.  For  example.  Op 
Code  X ' 1 2 f  will  cause  the  Address  field  of  the  Instruction  Register 
(IRA)  to  be  replaced  by  Data  Groups  2,  3,  and  4. 

Further,  status  data  from  the  AD/4  appearing  on  the  Output  Bus 
(OB)  will  be  sent  back  to  the  controlling  digital  computer  using 
the  format  M=0 ,  FF=10.  It  is  sent  through  the  Sender  Interface  on 
Data  Groups  1,  2,  3,  4  after  the  input  data  has  been  written. 

If  WOCF  has  been  previously  set  to  zero,  then  a  Read  Op  Code 
is  in  the  'OR'.  Data  appearing  on  the  Output  Bus  as  a  result  of 
the  Read  Op  Code  will  be  sent  back  to  the  controlling  digital  com¬ 
puter  via  Data  Groups  1,  2,  3,  and  4  of  the  Sender  Interface,  using 
the  format  M=0,  FF=11.  For  example,  Op  Code  X'16'  will  cause  the 
Address  field  of  the  Instruction  Register  (IRA)  to  be  placed  on  the 
OB,  becoming  in  turn  Data  Groups  2,  3,  and  4  sent  back  by  the  Sender. 
The  data  accompanying  the  control  command  for  WOCF=0  is  ignored. 

Access  and  Execute  a  Read  Op  Code 

M=1 ,  FF=00 ,  E=1 . 

This  command  loads  a  new  Op  Code  in  the  'OR'  as  in  "Access  a 
Read  Op  Code",  and  then  causes  the  Op  Code  to  be  executed  as  above 
("Execute  the  Op  Code")  with  WOCF=0. 

This  feature  reduces  the  number  of  transmissions  by  half  for 
Access  then  Execute  type  operations  for  reading  data  from  the  AD/4. 
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However,  there  is  a  class  of  Read  Op  Codes  in  the  AD/4  which  can 
make  use  of  one  Access  followed  by  many  Executes.  This  justifies 
the  dual  capability  provided  by  the  separate  Access  and  Execute 
commands  mentioned  previously. 

Access  and  Execute  a  Write  Op  Code 

M=1 ,  FF=01,  E=1 . 

This  command  loads  a  new  Op  Code  in  the  'OR'  as  above,  sets 
WOCF  to  one,  and  then  causes  the  Write  Op  Code  to  be  executed. 
This  command  is  used  only  when  the  data  to  be  written  consists  of 
two  or  three  bits.  (The  DAC  and  ADC  "update"  commands). 

Change  State  of  Device  Board 


M=0,  FF=01. 

This  command  indicates  that  the  state  of  the  interrupt  handler 
is  to  change  (enable/disable,  etc.),  or  that  some  other  function  of 
the  Device  Board  is  to  be  performed.  The  new  state  will  be  coded 
in  the  Data  Groups,  but  the  format  has  not  as  yet  been  determined. 


8.2.3  The  Interrupt  Handler 

The  HIF  has  the  capability  of  presenting  three  interrupts  to 
an  RIF.  They  are  CIO,  CI1  and  INT* .  These  interrupts  can  be  patched 
within  the  AD/4  to  accomplish  various  purposes.  For  example,  the 
change  in  state  of  an  Analog  to  Digital  Converter  could  be  indicated. 
Fault  conditions  of  various  kinds  can  also  be  patched.  These  are 
basically  choices  left  up  to  the  AD/4  user  and  installation  manage¬ 
ment  . 


The  Interrupt  Handler  will  cause  interrupt  status  data  to  be 
sent  to  the  controlling  digital  computer  whenever  any  of  these  three 
•signals  makes  a  positive  transition  (i.e.,  become  active).  The  for¬ 
mat  of  the  data  sent  to  the  digital  computer  is  M=l,  FF=11. 
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9  Conclusion 


A  system  has  been  presented  that  fulfills  the  need  at  the  University 
of  Toronto  for  an  interconnection  of  3  digital  machines.  Beyond  this, 
Star-Ring  has  the  potential  of  loosely  connecting  arbitrary  digital 
machines  together  at  high  data  rates.  Accordingly,  the  interface  to 
Star-Ring  is  straightforward  and  as  general  as  possible:  at  the  time 
of  writing  this  conclusion,  a  Calcomp  plotter  has  just  been  added  to 
the  Star-Ring  system  in  the  short  time  of  4  weeks. 

There  are  numerous  ways  Star-Ring  can  be  used  as  a  building  block 
for  larger  systems  of  interconnected  computer  facilities.  Through  the 
use  of  communications  links  connected  to  Star-Ring,  hierarchical  or  grid 
systems  of  Star-Rings  are  possible  and  have  intriguing  possibilities. 

The  actual  construction  of  Star-Ring  has  provided  the  author  with 
invaluable  experience  in  systems  and  logical  design.  It  is  hoped 
further  that  the  physical  existence  of  Star-Ring  will  point  out  larger 
problems  in  interaction  between  digital  devices  and  between  firmware 
systems  by  permitting  actual  operational  use.  The  real  construction  of 
Star-Ring,  rather  than  simulation,  has  already  made  possible  a  design 
that  takes  into  account  currently  available  technology.  It  also  prevented 
a  design  based  on  'a  priori'  assumptions  which  are  often  wrong  and  at  best 
first- level  approximations  that  ignore  many  physical  constraints. 

Finally,  there  are  bound  to  be  many  improvements  possible  in  the 
design  of  Star-Ring  which  have  been  overlooked.  An  attempt  has  been 
made  to  provide  a  hardware  system  that  fills  a  gap  in  available  equip¬ 
ment,  that  has  been  shown,  needs  to  be,  and  can  be,  filled. 
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Appendix  A 


Asynchronous  Decision  Element 


A  block  diagram  of  the  Asynchronous  Decision  Element  (ADE)  used 
in  all  Star-Ring  Control  design  is  shown  in  Fig.  13.  A  0  to  1  transi¬ 
tion  in  DN  causes  the  ADE  to  output  XT  or  XF  but  not  both  equal  to  1 
depending  on  the  value  of  X  just  prior  to  the  occurrence  of  DN.  After 
DN's  transition,  DN  can  go  back  to  0  without  changing  XT  or  XF.  More 
importantly,  X  has  no  more  effect  either. 

The  reset  connection  sets  up  the  ADE  for  another  decision  after 
XT  or  XF  has  been  used  to  initiate  one  of  two  control  paths. 

Fig.  13  also  shows  an  IC  realization  of  the  ADE  similar  to  that 
used  in  the  Sender  Control  of  Star- Ring. 

XT  will  go  to  1  (X=l)  much  more  quickly  than  XF  will,  if  X=0, 
because  of  the  IC  technology.  Thus  the  ADE  is  used  in  the  system  such 
that  XT  causes  the  beginning  of  a  long  and  highly  utilized  cycle  for 
data  transfer.  XF  will  start  the  shorter  default  cycle  (Sender  not 
ready)  where  its  longer  delay  to  1  will  not  be  as  critical. 

Jumper  J  is  used  in  Sender  Control  for  initialization  purposes  in 
the  whole  system  and  modifies  the  ADE ' s  reaction  to  DN  transitions. 

The  ADE  can  be  related  to  a  scheme  of  Control  design  known  as  Con¬ 
trol  Point  design  [13].  The  ADE  passes  Control  from  one  ADE  to  another 
by  positive  transitions  of  signals,  not  levels  as  in  Control  Point  design. 

The  ADE  has  been  refined  at  a  later  date  but  this  first  version  was 
used  in  the  Sender  Control. 
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ASYNCHRONOUS  DECISION  ELEMENT 


x 


DECIDE  NOW,DN 

_ r- 


ADE 

1 


XT(RUE) 

XF(ALSE) 

RESET 


POSSIBLE  OUTPUTS 
0  1  0 

0  0  1 


Fig.  13 
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